Databases synchronization

ABSTRACT

The invention deals with database synchronization. A first database is stored in a removable device for example a smartcard communicating with a first system. A second database of the same nature being stored in a second system communication with said first system. Said first and second system comprises means able to generate synchronization objects defining the last database synchronization which has been performed between said two databases of said two systems. After each synchronization step of the first database with the second database, a program external to the removable device sends a command to the removable device forsetting a synchronization object to said first database, said synchronization object being also affected to the second database which has been synchronized.

FIELD OF THE INVENTION

The present invention relates generally to communications systems and,in particular, to techniques that provide for synchronizing databases.Synchronization is the act of establishing equivalence between two datacollections, where each data item in one collection maps to a data itemin the other one, and each item and its respective mapping having acontent, which is the same, or equivalent or which corresponds topredefined requirements.

This invention particularly applies to removable devices, such as a SIM(Subscriber Identity Module) smartcard, that can be inserted intodifferent terminals.

In the context of the invention, a database has to be understood as adata container (e.g. table, file . . . ). No presumptions about itsstructure are needed.

In the same manner, an item is a specific data of a database. (e.g. arecord of a file, a row of a table, . . . )

PRIOR ART

Synchronization protocols are used to synchronize the content of adatabase owned by a first system, generally a client, with the contentof another database owned by a second system, which is generally aserver. Both systems can be connected and can exchange messages(synchronization messages) using different transfer/session protocols(e.g. HTTP (HyperText Transfer Protocol), WSP (Wireless SessionProtocol), . . . ).

The synchronization principles are basically the following:

-   -   Firstly, client and server systems arrange some initial        synchronization parameters (e.g. which databases are going to be        synchronized, type of synchronization . . . );    -   Secondly, one of them (the first system) sends the changes        (additions, modifications, . . . ) which have occurred since the        last time their databases were synchronized between themselves.        These changes are often stored in a file called ChangeLog file.        This ChangeLog file reflects all the modifications in particular        the identity of the database record for which the event occurred        and a timestamp indicating when the event took place.    -   Then, the second system processes the changeLog received        (modifying its database if required), and sends its own changLog        to the first system.    -   Following the changeLog received, the first system changes its        database if required.    -   Then, both systems exchange acknowledges and other finalization        messages if required, ending the synchronization process.

In the above process, the first system could be a mobile phone and thesecond system a personal assistant. Modifications may also occur in theSIM card coupled to the mobile phone. In this case, all themodifications, which occur in the SIM, are stored in the ChangeLog fileincluded in the first system. Nevertheless, two important facts must beconsidered when trying to define a smartcard synchronization solution:

-   -   The smartcard is a removable device that can be inserted into        different systems;    -   The content of the smartcard can be accessed and modified by        different systems using different transport mode (by APDU        (Application Protocol Data Unit) commands from the terminal, by        Over The Air (OTA) commands, etc. . . . ).

These two facts have a clear initial consequence:

-   -   For synchronization purposes, the smartcard cannot be managed as        a simple memory accessed by one system, because its memory is        not attached or controlled by a unique system.    -   Moreover, due to the lack of resources (memory, processing or        communication capabilities), the smartcard is not able to        support a complete synchronization protocol. In particular,        contrary to systems such as mobile phone or personal assistant,        a smartcard has no clock for dating a modification of its        content.

THE INVENTION

The main purpose of the invention is to provide a smartcard whichmanages its own modifications, ensuring a synchronization between adatabase stored in the smartcard itself instead of using a copy or thecorresponding ChangeLog stored in the mobile phone as in the prior art.

According to the invention, for databases synchronization purpose, aprogram external to the removable device sends a command to theremovable device for setting a synchronization object to said firstdatabase, a synchronization object being affected to said firstdatabase, said synchronization object being also affected to the seconddatabase once the synchronization step between the two databases hasbeen successfully performed, said object defining the last databasesynchronization which has been performed between said two databases.

In this way, a synchronization object is linked to a database in thesmart card, and this synchronization object is set by an externalprogram stored in a system outside the smartcard, this system having thenecessary resources for performing a database synchronization. So that,with the invention, the smartcard can be inserted in any device,ensuring a synchronization of its databases, independently of the systemwhich has modified its content.

It will be easier to understand the invention on reading the descriptionbelow, given as an example and referring to the attached drawings.

In the drawings:

FIG. 1 is a schematic view a system in which the invention can beapplied.

FIG. 2 is an algorithm illustrating the different steps of a practicalexample.

DETAILED DESCRIPTION OF A PRACTICAL EXAMPLE

FIG. 1 is a schematic view of a system SYS including a SIM card CARcoupled to a mobile phone MOB. In our example, this system SYS alsoincludes a digital assistant (PDA) communicating with the mobile by wayof a network IFR. This network could be for example an infraredconnection.

In our example, the card CAR stores a database DB1 and the assistantstores a database DB2. In another example, the second database could bestored in the smartcard CAR itself.

In our example, the mobile MOB, for example under user request, wants tosynchronize the database DB1 with the assistant database DB2 bothconnected by the infrared port.

In our example, each database DB1 and DB2 is a file of the same nature.More particularly, the database DB1 to be synchronized is the user'sphonebook contained in a file EF (Elementary File) of the user's cardCAR.

Generally, the Mobile equipment MOB is able to interrogate the smartcardusing APDU messages over the standard T=0 protocol. We will refer tothis standard for more explanations about this protocol.

According to the invention, the smartcard supports synchronizationobject managing and modification detection. In our example, the mobilephone MOB having access to the smartcard has three commands to get andexploit the information related to synchronization objects andmodification detection.

Synchronization objects will be linked to a database and represent aspecific state of the database after a successful synchronization with aspecific device.

In our example, there are three new commands fictitiously named NewSync,GetChanges, StoreSync. The functions of theses commands are explainedbelow:

NewSync: With this command, the mobile MOB informs to the smartcard thata new synchronization of the data of one of its database DB1 with asecond database (DB2) has to be performed. The smartcard answers withthe identifier of the synchronization object affected to the databaseDB1, if exists, defining the last time that this database DB1 has beensynchronized with the database DB2 (synchronization object is referredas “last synchronization object”). Preferably, It also proposes a newsynchronization object defining the state of the database after thiscurrent synchronization (“new synchronization object”).

GetChanges: With this command, the mobile MOB asks for the modificationsof the database DB1 which has occurred since the last synchronizationobject. The smartcard CARD answers with the identifiers of the databaseitems modified, added or deleted. Preferably, only the identifiers arereturned. So, if required, the mobile MOB could make use of its localcopy of the smartcard memory to follow with the synchronizationprotocol.

StoreSync: With this command, the mobile MOB informs to the smartcardCAR that the synchronization has been performed. (Changes may haveoccurred in the smartcard following the synchronization protocol managedby the device).

The smartcard CAR will replace the last synchronization object by thenew one, and will be henceforth able to detect further modifications inthe database DB1.

With these three commands, the smartcard CAR will provide a set ofactions required to perform a synchronization of data stored in thesmartcard, considering the problems and restrictions defined before.

The different steps (steps 1 to step 4) illustrating the invention willgive a better understanding of the invention.

Step 1

Before starting the synchronization protocol, the mobile MOB sends tothe smartcard CAR the NewSync command with the identifier of the PDA andthe name or identifier of the file DB1 to be synchronized. The smartcardremembers that a previous synchronization with the same PDA has beenperformed some times ago, with a synchronization object named“04012002131412”. In our example, the card sends back the lastsynchronization object identifier and proposes a new synchronizationobject identifier “05022002131412”.

Step 2

At this time, the mobile MOB starts a synchronization process with theassistant using one of the available synchronization protocols. Themobile MOB is able to initiate data synchronization with the PDA by thecorresponding exchange of initialization messages.

The last synchronization object provided by the smartcard CAR can beused in the synchronization protocol to be compared with the lastsynchronization object stored in the PDA:

-   -   If synchronization objects do not match (or any of them does not        exist), a full synchronization is requested by the        synchronization protocol. It means that both devices must        exchange all the data (of the ADN file). In this case no usage        of modification register is needed. All the database content is        supposed to have been modified (added). In this case, the mobile        sends a command [SLB3]to the card (CAR) for setting a        synchronization object to said first database (DB1), said        synchronization object being also affected to the second        database (DB2) which content has been synchronized with database        (DB1). Then, in this case, the synchronization process is        finished. The setting step is a configuration step in which the        generation of a synchronization object is requested.    -   If the two last synchronization objects match, it means that a        successful synchronization was performed in the past, and that        both devices may exchange only modifications occurred since this        last synchronization. In this case, the following step is Step        3.

Step 3

The mobile equipment may interrogate the smartcard to know about thechanges occurred since the moment when the last object was set. It sendsa GetChanges command, and the smartcard answers with the list of themodifications (e.g. “Added record 1 and 2, modified record 4, deletedrecord 7”). The mobile equipment MOB may then perform following commandsto know what has been the result of the modifications. For instance, itcan read the record 4 to see its value (maybe not if it has it in alocal copy).

In this step, the mobile MOB and the assistant exchange theirmodifications following the used synchronization protocol.

Once it has all data need it can continue the synchronization protocolsending the following messages with the client modifications andeventually receiving and performing the server modifications.

Step 4

Once the synchronization protocol is finished, the mobile MOB shall senda StoreSync command to the smartcard, to set the new synchronizationobject. Once this command is performed, the smartcard will be able todetect changes henceforward performed.

The smartcard stores the active synchronization object as the lastsynchronization object for future synchronization with the same PDA.Hereafter, the smartcard will be able to detect changes performed afterthis moment following commands in future synchronization.

Some additional comments can be added to this example:

-   -   If we insert the smartcard into another mobile MOB and we try to        synchronize again with the same PDA, synchronization can be        performed because change detection and synchronization objects        management are independent from the system in which is inserted        the smartcard.    -   Advantageously, synchronization of both devices can be performed        in any protocol supported by them because, the 3 commands        included in the synchronization procedure preferably does not        force any specific requirement to the synchronization protocol.    -   Any other device having access to the smartcard and to the three        new synchronization commands as illustrated in our example can        substitute the mobile. (e.g. OTA server);    -   The methods defined can also be used to synchronize smartcard        data with the local copy of the smartcard data in the mobile        equipment. This is a local synchronization between the smartcard        and the mobile equipment.

Generally, the invention provides some interesting features.

In our illustrated invention, we have seen that, for databasessynchronization purpose, an external program reads the synchronizationobject in the removable device and compares it with the synchronizationobject affected to the second database, compares them, and function ofthis result, synchronizes data in the databases. The external programcan be located in the mobile phone or in another system communicatingwith this mobile phone. So that, when a synchronization process has tobe performed in the future between a first and a second databases(DB1,DB2), the synchronization object is used because defining the lastdatabase synchronization which has been performed between said twodatabases (DB1,DB2),

We have also seen that, for initiating a synchronization step, the firstsystem (MOB) informs to the removable device CAR that a newsynchronization of the data of one of its databases with another system(PDA) is to be performed, then the removable device CAR answers with thecurrent synchronization object, if exists, defines the last time thatthis database has been synchronized with this system PDA, and alsoproposes a new synchronization object, for future use, defining thestate of the database after the current synchronization. The old and thenew synchronization object can be sent in a same message or in twodifferent messages.

We have also seen that when the first device MOB asks for themodifications of the database, which have occurred since the lastsynchronization object, the removable device answers with theidentifiers of the database items modified, added or deleted.Preferably, only the identifiers of the database items are returned, thedevice MOB being able to make use of its local copy of the removabledevice CAR memory to obtain the database content and to follow with thedata synchronization process.

We have also seen that the device MOB preferably informs to theremovable device MOB that the synchronization has been performed. Theremovable device replaces the last synchronization object by the newone, this new synchronization object being able to detect furthermodifications since the last synchronization.

Preferably, the mobile MOB sends, for information, a command to theremovable device with the identifier of the device and the name of thedatabase to be synchronized.

The invention also deals with a removable device, in particular a smartcard CAR. After each synchronization step of said database DB1 with saidsecond database DB2, the smart card receives a command initiated by anexternal device requesting to set a synchronization object to said firstdatabase DB1, said synchronization object being also affected to anoutside second database (DB2) which content has been synchronized withdatabase DB1.

The invention also deals with a system MOB able to communicate with aremovable device CAR. This system comprises a program for sending, whensynchronization between the two databases (DB1,DB2) has been performed,a command to said removable device CAR for setting a new synchronizationobject, said new synchronization object being also affected to thesecond database DB2 which content has been synchronized with databaseDB1.

We see now that the invention offers many advantages. The inventionprovides a method to manage its modifications and interfaces to accessto these methods whatever the entity accessing to the smartcard is. Ineasier words, the smartcard performs some required actions to beintegrated in the synchronization process. So that, the smartcard isable to support a complete synchronization protocol.

1. A method for synchronizing data stored in two different databases ofthe same nature, at least one of the two databases being stored in aremovable device, in particular a smartcard, said removable devicecommunicating with a system, characterized in that, for databasessynchronization purpose, a program external to said removable devicesends a command to the removable device for setting a synchronizationobject to said first database, a synchronization object being affectedto said first database, said synchronization objecting being alsoaffected to the second database once the synchronization step betweenthe two databases has been successfully performed, said object definingthe last database synchronization which has been performed between saidtwo databases.
 2. The method according to claim 1, characterized in thatit comprises, when a later synchronization process has to be performedbetween the first and the second databases, the step of reading thesynchronization object affected to the first database and compares itwith the synchronization object affected to the second database, and ifthe objects matches, each of the records that was modified from one ofthe databases is modified in the other database.
 3. The method accordingto claim 2, characterized in that it comprises, when a system initiatesa synchronization step, the step of informing to the removable devicethat a new synchronization of the data of the first database with saidsecond database, then the removable device answers with the currentsynchronization object, if exists, defines the last time that thisdatabase has been synchronized with this second database, and alsoproposes a new synchronization object, for future use, defining thestate of the database after the current synchronization is finished. 4.The method according to claim 1, characterized in that the externalprogram asks for the modifications of the first database, which hasoccurred since the last synchronization object, and the removable deviceanswers with the identifiers of the database items modified, added ordeleted.
 5. The method according to claim 4, characterized in that thedevice is able to make use of a local copy of the removable devicememory to obtain the database content and to follow with the datasynchronization process.
 6. The method according to claim 1,characterized in that the device informs to the removable device thatthe synchronization has been successfully performed, the removabledevice replacing the last synchronization object by the new one, thisnew synchronization object being able to detect further modificationssince the current synchronization.
 7. The method according to claim 1,characterized in that the synchronization object is a random numbergenerated in the removable device.
 8. A removable device, in particulara smart card, being able to communicate with a system, said removabledevice including a first database able to be synchronized with a seconddatabase of the same nature, characterized in that it comprises meansfor, when a synchronization step is initiated between said twodatabases, receiving a command initiated by an external systemrequesting to set a synchronization object to said first database, asynchronization object being affected to said first database, saidsynchronization object being also affected to the second database oncethe synchronization step between the two databases has been successfullyperformed, said object defining the last database synchronization whichhas been performed between said two databases.
 9. A system able tocommunicate with a removable device, in particular a smart card, saidremovable device including a first database to be synchronized with asecond database of the same nature, characterized in that it comprises aprogram for setting each time a synchronization step is initiatedbetween said two databases, a synchronization object to said databasefor affecting a synchronization object to said first database, thissynchronization object being also affected to said second database oncethe synchronization step between the two databases has been successfullyperformed, said object defining the last database synchronization whichhas been performed between said two databases of said two system.
 10. Acomputer program product for system able to communicate with a removabledevice, said removable device storing a first database to besynchronized with a second database, the computer program productincluding an instruction set which when the instruction set is loaded inthe system, makes the system perform, when a synchronization isinitiated between said first database and said second database, asetting step in which a command is send to said removable device forsetting a synchronization object to said first database, asynchronization object being affected to said first database, saidsynchronization object being also affected to the second database oncethe synchronization step between the two databases has been successfullyperformed, said object defining the last database synchronization whichhas been performed between said two databases and being used for futuresynchronization step between these two databases.
 11. A computer programproduct for a removable device able to communicate with a system, saidremovable device storing a first database to be synchronized with asecond database, the computer program product including an instructionset which when the instruction set is loaded in the system, makes theremovable device, when a synchronization is initiated between said firstdatabase and said second database, A receiving step in which theremovable device receives a command coming from an external system, saidcommand having the function of setting a synchronization object, Anexecution step in which said program executes the command in setting thegeneration of a synchronization object to be affected to said firstdatabase, said synchronization object being also affected to the seconddatabase once the synchronization step between the two databases hasbeen successfully performed, said object defining the last databasesynchronization which has been performed between said two databases. 12.The program according to claim 11, characterized in that thesynchronization object includes a random number.
 13. The methodaccording to claim 3, characterized in that the device informs to theremovable device that the synchronization has been successfullyperformed, the removable device replacing the last synchronizationobject by the new one, this new synchronization object being able todetect further modifications since the current synchronization.